<p>Promoted attributes are <a href="#root/_help_zEY4DaJG4YT5">attributes</a> which
  are considered important and thus are "promoted" onto the main note UI.
  See example below:</p>
<p>
  <img src="Promoted Attributes_promot.png">
</p>
<p>You can see the note having kind of form with several fields. Each of
  these is just regular attribute, the only difference is that they appear
  on the note itself.</p>
<p>Attributes can be pretty useful since they allow for querying and script
  automation etc. but they are also inconveniently hidden. This allows you
  to select few of the important ones and push them to the front of the user.</p>
<p>Now, how do we make attribute to appear on the UI?</p>
<h2>Attribute definition</h2>
<p>Attribute is always name-value pair where both name and value are strings.</p>
<p><em>Attribute definition</em> specifies how should this value be interpreted
  - is it just string, or is it a date? Should we allow multiple values or
  note? And importantly, should we <em>promote</em> the attribute or not?</p>
<p>
  <img src="Promoted Attributes_image.png">
</p>
<p>You can notice tag attribute definition. These "definition" attributes
  define how the "value" attributes should behave.</p>
<p>So there's one attribute for value and one for definition. But notice
  how definition attribute is <a href="#root/_help_bwZpz2ajCEwO">Inheritable</a>,
  meaning that it's also applied to all descendant note. So in a way, this
  definition is used for the whole subtree while "value" attributes are applied
  only for this note.</p>
<h3>Inverse relation</h3>
<p>Some relations always occur in pairs - my favorite example is on the family.
  If you have a note representing husband and note representing wife, then
  there might be a relation between those two of <code>isPartnerOf</code>.
  This is bidirectional relationship - meaning that if a relation is pointing
  from husband to wife then there should be always another relation pointing
  from wife to husband.</p>
<p>Another example is with parent - child relationship. Again these always
  occur in pairs, but in this case it's not exact same relation - the one
  going from parent to child might be called <code>isParentOf</code> and the
  other one going from child to parent might be called <code>isChildOf</code>.</p>
<p>Relation definition allows you to specify such "inverse relation" - for
  the relation you just define you specify which is the inverse relation.
  Note that in the second example we should have two relation definitions
  - one for <code>isParentOf</code> which defines <code>isChildOf</code> as inverse
  relation and then second relation definition for <code>isChildOf</code> which
  defines <code>isParentOf</code> as inverse relation.</p>
<p>What this does internally is that whenever we save a relation which has
  defined inverse relation, we check that this inverse relation exists on
  the relation target note. Similarly, when we delete relation, we also delete
  inverse relation on the target note.</p>